Formalism and Informalism in Software Architectural Style: a Case Study

Architectural style is increasingly recognized as an important element of software architectural design. An expanding body of research (e.g. [GS93, PW92, DAR90, MQ94, AAG93]) is recognizing that when developing a particular system, designers tend not to explore all possible alternatives for its architecture. Instead, they use specific structures and idioms that are effective for the domain in which they are working. We term such a collection of patterns and idioms an architectural style. These patterns and idioms constrain the design space, permitting developers to ignore complications and alternatives that are not relevant to the system they are developing. By focusing on fewer, relevant alternatives, the issues that are most important are exposed and the developer is thus helped to make effective choices and locate a solution more easily. In addition, by guaranteeing properties of all systems constructed using the style, the cost of analyzing these systems is reduced. For example, in “Deadlock-free Configuration Programming”[JC94], Justo and Cunha describe a collection of component templates and connectors that, when used to construct a system, can provide guarantees about the deadlocking behavior (or, preferably, the deadlock-freedom) of a configured system. By restricting the form of design elements permitted as components in their systems, they reduce the cost of the deadlock analysis to a simple static check. Unfortunately, with few exceptions current exploitation of architectural style is informal and ad hoc [DAR90]. The choice of style in a system is often based on the development team’s shared